Web Security Headers: Content Security Policy og JavaScript-eksekvering

I nutidens komplekse digitale landskab er sikkerheden for webapplikationer altafgørende. Et af de mest effektive forsvar mod forskellige angreb, især Cross-Site Scripting (XSS), er brugen af Web Security Headers. Blandt disse skiller Content Security Policy (CSP) sig ud som en kraftfuld mekanisme til at kontrollere, hvilke ressourcer en browser har tilladelse til at indlæse for en given side. Denne artikel giver en omfattende guide til at forstå og implementere CSP effektivt for at beskytte dine webapplikationer og brugere.

Forståelse af Web Security Headers

Web Security Headers er HTTP-response-headers, der giver browseren instruktioner om, hvordan den skal opføre sig, når den håndterer bestemte typer indhold. De er en afgørende del af en dybdegående forsvarsstrategi og arbejder sammen med andre sikkerhedsforanstaltninger for at mindske risici.

Nogle af de mest almindeligt anvendte web security headers inkluderer:

• Content Security Policy (CSP): Kontrollerer, hvilke ressourcer brugeragenten har tilladelse til at indlæse.
• HTTP Strict Transport Security (HSTS): Tvinger browsere til at bruge HTTPS.
• X-Frame-Options: Beskytter mod Clickjacking-angreb.
• X-Content-Type-Options: Forhindrer MIME-sniffing-sårbarheder.
• Referrer-Policy: Kontrollerer, hvor meget referrer-information der skal inkluderes i anmodninger.
• Permissions-Policy (tidligere Feature-Policy): Giver granulær kontrol over browserfunktioner.

Denne artikel fokuserer primært på Content Security Policy (CSP) og dens indvirkning på JavaScript-eksekvering.

Hvad er Content Security Policy (CSP)?

CSP er en HTTP-response-header, der giver dig mulighed for at definere en hvidliste over kilder, hvorfra browseren har tilladelse til at indlæse ressourcer. Dette inkluderer JavaScript, CSS, billeder, skrifttyper og andre aktiver. Ved eksplicit at definere disse betroede kilder kan du markant reducere risikoen for XSS-angreb, hvor ondsindede scripts injiceres på dit website og eksekveres i konteksten af dine brugeres browsere.

Tænk på CSP som en firewall for din browser, men i stedet for at blokere netværkstrafik, blokerer den eksekveringen af ikke-betroet kode.

Hvorfor er CSP vigtig for JavaScript-eksekvering?

JavaScript er et kraftfuldt sprog, der kan bruges til at skabe dynamiske og interaktive weboplevelser. Dets fleksibilitet gør det dog også til et primært mål for angribere. XSS-angreb involverer ofte injektion af ondsindet JavaScript-kode på et website, som derefter kan bruges til at stjæle brugeroplysninger, omdirigere brugere til phishing-sider eller ødelægge websitet.

CSP kan effektivt forhindre disse angreb ved at begrænse de kilder, hvorfra JavaScript kan indlæses og eksekveres. Som standard blokerer CSP al inline JavaScript (kode inden i <script>-tags) og JavaScript, der indlæses fra eksterne domæner. Du kan derefter selektivt aktivere betroede kilder ved hjælp af CSP-direktiver.

CSP-direktiver: Byggestenene i din politik

CSP-direktiver definerer, hvilke typer ressourcer der må indlæses, og fra hvilke kilder de kan indlæses. Her er nogle af de vigtigste direktiver:

• default-src: Fungerer som en fallback for andre fetch-direktiver. Hvis et specifikt direktiv ikke er defineret, bruges default-src.
• script-src: Angiver de tilladte kilder for JavaScript-kode.
• style-src: Angiver de tilladte kilder for CSS-stylesheets.
• img-src: Angiver de tilladte kilder for billeder.
• font-src: Angiver de tilladte kilder for skrifttyper.
• media-src: Angiver de tilladte kilder for lyd- og videofiler.
• object-src: Angiver de tilladte kilder for plugins (f.eks. Flash).
• frame-src: Angiver de tilladte kilder for frames (<frame>, <iframe>).
• connect-src: Angiver de tilladte oprindelser for netværksanmodninger (f.eks. XMLHttpRequest, Fetch API, WebSockets).
• base-uri: Begrænser de URL'er, der kan bruges i et dokuments <base>-element.
• form-action: Begrænser de URL'er, som formularer kan sendes til.
• upgrade-insecure-requests: Instruerer browseren i at opgradere alle usikre URL'er (HTTP) til sikre URL'er (HTTPS).
• block-all-mixed-content: Forhindrer browseren i at indlæse ressourcer via HTTP, når siden er indlæst over HTTPS.

Hvert direktiv kan acceptere en række kildeudtryk, herunder:

• *: Tillader ressourcer fra enhver kilde (generelt ikke anbefalet).
• 'self': Tillader ressourcer fra samme oprindelse (skema, vært og port) som dokumentet.
• 'none': Tillader ikke ressourcer fra nogen kilder.
• 'unsafe-inline': Tillader brugen af inline JavaScript og CSS (stærkt frarådet).
• 'unsafe-eval': Tillader brugen af eval() og relaterede funktioner (stærkt frarådet).
• 'unsafe-hashes': Tillader specifikke inline event-handlers baseret på deres SHA256-, SHA384- eller SHA512-hash (skal bruges med forsigtighed).
• data:: Tillader data: URI'er (f.eks. inline-billeder kodet som base64).
• https://example.com: Tillader ressourcer fra det angivne domæne (og valgfri port) over HTTPS.
• *.example.com: Tillader ressourcer fra ethvert subdomæne af example.com.
• nonce-{random-value}: Tillader specifikke inline-scripts eller -styles, der har et matchende nonce-attribut (anbefales til inline-kode).
• sha256-{hash-value}: Tillader specifikke inline-scripts eller -styles, der har et matchende SHA256-hash (alternativ til nonces).

Implementering af CSP: Praktiske eksempler

Der er to primære måder at implementere CSP på:

1. HTTP Header: At sende Content-Security-Policy-headeren i HTTP-responsen. Dette er den foretrukne metode.
2. <meta> Tag: At bruge et <meta>-tag i <head>-sektionen af HTML-dokumentet. Denne metode har begrænsninger og anbefales generelt ikke.

Brug af HTTP Header

For at indstille CSP-headeren skal du konfigurere din webserver. De nøjagtige trin varierer afhængigt af din server (f.eks. Apache, Nginx, IIS).

Her er nogle eksempler på CSP-headers:

Grundlæggende CSP

Denne politik tillader kun ressourcer fra samme oprindelse:

            Content-Security-Policy: default-src 'self';
            

              
                Copy
              
            
          

Tilladelse af ressourcer fra specifikke domæner

Denne politik tillader JavaScript fra https://cdn.example.com og billeder fra https://images.example.net:

            Content-Security-Policy: default-src 'self'; script-src 'self' https://cdn.example.com; img-src 'self' https://images.example.net;
            

              
                Copy
              
            
          

Brug af nonces til inline-scripts

Denne politik tillader inline-scripts, der har et matchende nonce-attribut:

            Content-Security-Policy: default-src 'self'; script-src 'self' 'nonce-rAnd0mN0nc3';
            

              
                Copy
              
            
          

I din HTML:

            <script nonce="rAnd0mN0nc3">
 // Dit inline-script
</script>
            

              
                Copy
              
            
          

Bemærk: Nonce-værdien skal genereres tilfældigt for hver anmodning for at forhindre angribere i at omgå CSP'en.

Brug af hashes til inline-scripts

Denne politik tillader specifikke inline-scripts baseret på deres SHA256-hash:

            Content-Security-Policy: default-src 'self'; script-src 'self' 'sha256-qznLcsROx4GACP2dm0UCKCzCG+HiZ1guq6ZZDob/Tng=';
            

              
                Copy
              
            
          

For at generere SHA256-hashen kan du bruge en række onlineværktøjer eller kommandolinjeværktøjer (f.eks. openssl dgst -sha256 -binary input.js | openssl base64).

Brug af <meta>-tagget

Selvom det ikke anbefales til komplekse politikker, kan <meta>-tagget bruges til at indstille en grundlæggende CSP. For eksempel:

            <meta http-equiv="Content-Security-Policy" content="default-src 'self';">
            

              
                Copy
              
            
          

Begrænsninger for <meta>-tagget:

• Kan ikke bruges til at specificere report-uri-direktivet.
• Ikke så bredt understøttet som HTTP-headeren.
• Mindre fleksibel og sværere at administrere for komplekse politikker.

CSP Report-Only-tilstand

Før du håndhæver en CSP, anbefales det kraftigt at bruge Content-Security-Policy-Report-Only-headeren. Dette giver dig mulighed for at overvåge virkningen af din politik uden rent faktisk at blokere nogen ressourcer. Browseren vil rapportere eventuelle overtrædelser til en specificeret URL, hvilket giver dig mulighed for at finjustere din politik, før du implementerer den i produktion.

            Content-Security-Policy-Report-Only: default-src 'self'; report-uri /csp-report;
            

              
                Copy
              
            
          

Du skal konfigurere et server-side-endepunkt (f.eks. /csp-report) til at modtage og behandle CSP-rapporterne. Disse rapporter er typisk JSON-objekter, der indeholder information om det overtrådte direktiv, den blokerede URI og andre relevante detaljer.

Almindelige CSP-fejl og hvordan man undgår dem

Implementering af CSP kan være en udfordring, og det er let at begå fejl, der enten kan svække din sikkerhed eller ødelægge dit website. Her er nogle almindelige faldgruber, du bør undgå:

• Brug af 'unsafe-inline' og 'unsafe-eval': Disse direktiver deaktiverer i bund og grund den beskyttelse, som CSP tilbyder, og bør undgås, når det er muligt. Brug nonces eller hashes til inline-scripts og undgå at bruge eval().
• Brug af *: At tillade ressourcer fra enhver kilde underminerer formålet med CSP. Vær så specifik som muligt, når du definerer din politik.
• Ikke at teste grundigt: Test altid din CSP i report-only-tilstand, før du håndhæver den. Overvåg rapporterne og juster din politik efter behov.
• Forkert konfiguration af report-uri: Sørg for, at dit report-uri-endepunkt er korrekt konfigureret til at modtage og behandle CSP-rapporter.
• Manglende opdatering af din CSP: I takt med at dit website udvikler sig, kan din CSP have brug for at blive opdateret for at afspejle ændringer i dine ressourceafhængigheder.
• Alt for restriktive politikker: Politikker, der er for restriktive, kan ødelægge dit website og frustrere brugerne. Find en balance mellem sikkerhed og brugervenlighed.

CSP og tredjepartsbiblioteker

Mange websites er afhængige af tredjepartsbiblioteker og -tjenester, såsom CDN'er, analyseudbydere og sociale medier-widgets. Når du implementerer CSP, er det vigtigt at tage højde for disse afhængigheder og sikre, at din politik tillader dem at indlæse ressourcer korrekt.

Her er nogle strategier til håndtering af tredjepartsbiblioteker:

• Hvidlist eksplicit domænerne for betroede tredjepartsudbydere: Hvis du f.eks. bruger jQuery fra et CDN, skal du tilføje CDN'ets domæne til dit script-src-direktiv.
• Brug Subresource Integrity (SRI): SRI giver dig mulighed for at verificere, at de filer, du indlæser fra tredjepartskilder, ikke er blevet manipuleret. For at bruge SRI skal du generere en kryptografisk hash af filen og inkludere den i <script>- eller <link>-tagget.
• Overvej at hoste tredjepartsbiblioteker på din egen server: Dette giver dig mere kontrol over ressourcerne og reducerer din afhængighed af eksterne udbydere.

Eksempel med brug af SRI:

            <script
 src="https://cdn.example.com/jquery.min.js"
 integrity="sha384-vtXRMe3mGCkKsTB9UMvnoknreNzcMRujMQFFSQhtI2zxLlClmHsfq9em6JzhbqQ"
 crossorigin="anonymous"></script>
            

              
                Copy
              
            
          

CSP og Single-Page Applications (SPA'er)

SPA'er er ofte stærkt afhængige af JavaScript og dynamisk kodegenerering, hvilket kan gøre implementering af CSP mere udfordrende. Her er nogle tips til at sikre SPA'er med CSP:

• Undgå at bruge 'unsafe-eval': SPA'er bruger ofte templating-motorer eller andre teknikker, der er afhængige af eval(). Overvej i stedet at bruge alternative tilgange, der ikke kræver eval(), såsom forudkompilerede skabeloner.
• Brug nonces eller hashes til inline-scripts: SPA'er injicerer ofte JavaScript-kode dynamisk. Brug nonces eller hashes for at sikre, at kun betroet kode eksekveres.
• Konfigurer connect-src-direktivet omhyggeligt: SPA'er laver ofte API-anmodninger til forskellige endepunkter. Sørg for kun at hvidliste de nødvendige domæner i connect-src-direktivet.
• Overvej at bruge et CSP-bevidst framework: Nogle JavaScript-frameworks tilbyder indbygget understøttelse af CSP, hvilket gør det lettere at implementere og vedligeholde en sikker politik.

CSP og internationalisering (i18n)

Når man udvikler webapplikationer til et globalt publikum, er det vigtigt at overveje virkningen af CSP på internationalisering (i18n). Her er nogle faktorer, man skal huske på:

• Content Delivery Networks (CDN'er): Hvis du bruger et CDN til at levere dit websites aktiver, skal du sørge for at hvidliste CDN'ets domæner i din CSP. Overvej at bruge forskellige CDN'er til forskellige regioner for at optimere ydeevnen.
• Eksterne skrifttyper: Hvis du bruger eksterne skrifttyper (f.eks. Google Fonts), skal du sørge for at hvidliste skrifttypeudbydernes domæner i dit font-src-direktiv.
• Lokaliseret indhold: Hvis du serverer forskellige versioner af dit website til forskellige sprog eller regioner, skal du sørge for, at din CSP er konfigureret korrekt for hver version.
• Tredjepartsintegrationer: Hvis du integrerer med tredjepartstjenester, der er specifikke for visse regioner, skal du sørge for at hvidliste domænerne for disse tjenester i din CSP.

Bedste praksis for CSP: Et globalt perspektiv

Her er nogle generelle bedste praksisser for implementering af CSP, der tager højde for et globalt perspektiv:

• Start med en restriktiv politik: Begynd med en politik, der blokerer alt som standard, og aktiver derefter selektivt betroede kilder.
• Brug report-only-tilstand først: Test din CSP i report-only-tilstand, før du håndhæver den, for at identificere potentielle problemer.
• Overvåg CSP-rapporter: Gennemgå regelmæssigt CSP-rapporter for at identificere potentielle sikkerhedssårbarheder og finjustere din politik.
• Brug nonces eller hashes til inline-scripts: Undgå at bruge 'unsafe-inline' og 'unsafe-eval'.
• Vær specifik med dine kildelister: Undgå at bruge wildcards (*), medmindre det er absolut nødvendigt.
• Brug Subresource Integrity (SRI) for tredjepartsressourcer: Verificer integriteten af filer, der indlæses fra CDN'er.
• Hold din CSP opdateret: Gennemgå og opdater din CSP regelmæssigt for at afspejle ændringer i dit website og dine afhængigheder.
• Uddan dit team: Sørg for, at dine udviklere og dit sikkerhedsteam forstår vigtigheden af CSP, og hvordan man implementerer det korrekt.
• Overvej at bruge en CSP-generator eller et administrationsværktøj: Disse værktøjer kan hjælpe dig med at oprette og vedligeholde din CSP lettere.
• Dokumenter din CSP: Dokumenter din CSP-politik og begrundelserne bag hvert direktiv for at hjælpe fremtidige udviklere med at forstå og vedligeholde den.

Konklusion

Content Security Policy er et kraftfuldt værktøj til at afbøde XSS-angreb og forbedre sikkerheden i dine webapplikationer. Ved omhyggeligt at definere en hvidliste over betroede kilder kan du markant reducere risikoen for eksekvering af ondsindet kode og beskytte dine brugere mod skade. Implementering af CSP kan være en udfordring, men ved at følge de bedste praksisser, der er beskrevet i denne artikel, og tage højde for de specifikke behov for din applikation og dit globale publikum, kan du skabe en robust og effektiv sikkerhedspolitik, der beskytter dit website og dine brugere verden over.

Husk, at sikkerhed er en løbende proces, og CSP er kun en brik i puslespillet. Kombiner CSP med andre sikkerhedsforanstaltninger, såsom inputvalidering, output-kodning og regelmæssige sikkerhedsrevisioner, for at skabe en omfattende, dybdegående forsvarsstrategi.

Yderligere ressourcer

• Content Security Policy (CSP) - MDN Web Docs
• CSP Evaluator
• Content-Security-Policy.com